Changes between Version 69 and Version 70 of Installing Pidgin

Timestamp:

Jun 23, 2012, 3:32:44 PM (12 years ago)

Author:

michaelz

Comment:

Changed all MTN/Monotone references to Mercurial.

Installing Pidgin

@@ -81 +81 @@
 This will install libpurple, Pidgin and Finch to `/usr/local`.  If you want to install it elsewhere, pass `--prefix=/some/other/prefix` to `./configure`.  (You really ''don't'' want to install it to `/usr`.)  See `./configure --help` for other options you can change at compile-time.
 
-If you got the source tree from our Monotone database ([wiki:"Installing Pidgin#WhydoyoualwayssaynottouseMTN" which you probably shouldn't have]), you'll need to run `./autogen.sh` instead of `./configure` the first time around. If you get an error like the following, you may need a newer version of automake.
+If you got the source tree from our Mercurial database ([wiki:"Installing Pidgin#WhydoyoualwayssaynottousetheMercurialrepository" which you probably shouldn't have]), you'll need to run `./autogen.sh` instead of `./configure` the first time around. If you get an error like the following, you may need a newer version of automake.
 
 {{{
@@ -137 +137 @@
 If you compiled the old version yourself, run `make uninstall` from the old source tree.  If you didn't keep that around but you remember the exact arguments you gave the configure script, you can download the source for the old release, configure it exactly the same, then run `make uninstall`.
 
-=== Why do you always say not to use MTN? ===
-That's a long story.  For starters,  MTN is frequently unusable because of changes in the code.  Bugs are introduced during the development process and are hopefully fixed before a release is made.  It is often the case that Pidgin MTN exhibits bad behavior due to features and bugfixes which are in a transitory state or which are not yet well understood.  These bad behaviors range from the harmless (maybe a graphical glitch in a dialog box) to the irritating (a particular protocol may not work), to the downright damaging (recently a bug in MTN destroyed the user's buddy lists).  While behaviors like this are acceptable to some users (particularly developers, who are used to such things), they tend to cause many Pidgin MTN users to contact Pidgin developers and report the same (usually egregious) bug over and over - using time which could be better spent fixing the bugs.
+=== Why do you always say not to use the Mercurial repository? ===
+That's a long story.  For starters, the Mercurial main branch is frequently unusable because of changes in the code.  Bugs are introduced during the development process and are hopefully fixed before a release is made.  It is often the case that Pidgin main exhibits bad behavior due to features and bugfixes which are in a transitory state or which are not yet well understood.  These bad behaviors range from the harmless (maybe a graphical glitch in a dialog box) to the irritating (a particular protocol may not work), to the downright damaging (recently a bug in the repository destroyed the user's buddy lists).  While behaviors like this are acceptable to some users (particularly developers, who are used to such things), they tend to cause many Pidgin Mercurial users to contact Pidgin developers and report the same (usually egregious) bug over and over - using time which could be better spent fixing the bugs.
 
-A second major point involves public resources - an MTN pull is not a cheap operation.  As many !SourceForge users are aware, at various points in the past few years !SourceForge CVS has been less than pleasant to work with.  This is, of course, because !SourceForge hosts thousands of useful and active projects which use[d] CVS as a primary method of source code collaboration.  Unfortunately, when too many users are poking around in that CVS just for the sake of poking around, it prevents other users who are trying to do work to improve those very same projects from accomplishing their tasks.  Naturally, this could  easily become true of our MTN offering as well. It is better for the community if an enterprising individual wishing to fix a particular bug [s]he has seen can get to the code and create a patch, even if this means that some users have to wait a few weeks for the next release to see what new features it might hold.
+A second major point involves public resources - an hg pull is not a cheap operation.  As many !SourceForge users are aware, at various points in the past few years !SourceForge CVS has been less than pleasant to work with.  This is, of course, because !SourceForge hosts thousands of useful and active projects which use[d] CVS as a primary method of source code collaboration.  Unfortunately, when too many users are poking around in that CVS just for the sake of poking around, it prevents other users who are trying to do work to improve those very same projects from accomplishing their tasks.  Naturally, this could  easily become true of our Mercurial offering as well. It is better for the community if an enterprising individual wishing to fix a particular bug [s]he has seen can get to the code and create a patch, even if this means that some users have to wait a few weeks for the next release to see what new features it might hold.
 
-The third point is not a problem which has yet come up, but it is in the back of the mind of the developers who bring you Pidgin.  As a third-party IM client, Pidgin is not a priority (and indeed may be an irritant) for the IM service providers.  We do our best to keep Pidgin playing nice and being friendly on the IM networks it uses; however, at times there are bugs in the protocol support.  If a few dozen people are using this buggy client, the IM providers are not likely to go out of their way to do anything about it.  However, if hundreds of people are pointing an ill-behaved client at an IM server, the server administrators may be forced to take action.  (This is particularly likely if the buggy behavior is damaging in some way.)  Pidgin releases represent code which the Pidgin developers feel is relatively well-behaved and stable.  This includes not only the interface seen by Pidgin users, but the traffic seen by IM service providers.  Pidgin MTN bears no such guarantees.
+The third point is not a problem which has yet come up, but it is in the back of the mind of the developers who bring you Pidgin.  As a third-party IM client, Pidgin is not a priority (and indeed may be an irritant) for the IM service providers.  We do our best to keep Pidgin playing nice and being friendly on the IM networks it uses; however, at times there are bugs in the protocol support.  If a few dozen people are using this buggy client, the IM providers are not likely to go out of their way to do anything about it.  However, if hundreds of people are pointing an ill-behaved client at an IM server, the server administrators may be forced to take action.  (This is particularly likely if the buggy behavior is damaging in some way.)  Pidgin releases represent code which the Pidgin developers feel is relatively well-behaved and stable.  This includes not only the interface seen by Pidgin users, but the traffic seen by IM service providers.  Pidgin Mercurial bears no such guarantees.
 
-In short, there are a lot of good reasons to ''not'' use Pidgin MTN if one does not wish to develop Pidgin, Pidgin plugins, or a codebase which interacts with Pidgin in some intimate way.  There are, however, only a few reasons ''to'' use Pidgin MTN outside of the above.  Please weigh these things carefully and decide whether you wish to use Pidgin MTN for a good reason which furthers the community, or for selfish reasons which are not entirely important.
+In short, there are a lot of good reasons to ''not'' use Pidgin Mercrial if one does not wish to develop Pidgin, Pidgin plugins, or a codebase which interacts with Pidgin in some intimate way.  There are, however, only a few reasons ''to'' use Pidgin Mercurial outside of the above.  Please weigh these things carefully and decide whether you wish to use Pidgin Mercurial for a good reason which furthers the community, or for selfish reasons which are not entirely important.